\documentclass[a4paper, 12pt]{report}
\usepackage[utf8]{inputenc}
\usepackage[french]{babel}
\usepackage[T1]{fontenc}
\usepackage{geometry} 
\usepackage{graphicx}
\usepackage[cc]{titlepic}
\usepackage{hyperref}
\usepackage{fancyhdr}
\usepackage{fancyvrb}  
\usepackage{color} 

\title{\includegraphics[scale=.4]{img/femto.png}\\\vspace{2cm}
\textbf{Plugin Eclipse pour la modélisation graphique}\\\vspace{1cm}Master 2 CODES -- Projet semestriel\\\vspace{.5cm}}

\author{IBRAHIMLI Nihat \& COUPEY Julien\\}

\date{2013-2014\\\vspace{1cm}} 

\titlepic{
\centering 
\includegraphics[scale=.7]{img/logo-ufc.png}
}

\pagestyle{fancy}
\fancyhead[L]{Master 2 CODES - Projet semestriel}
\fancyhead[R]{IBRAHIMLI Nihat \& COUPEY Julien}

\begin{document}
\maketitle

\thanks{~\vspace{1cm}

  \section*{Remerciements}

  \begin{enumerate}
  \item[$\bullet$] \textbf{Sébastien CHIPEAUX}  pour ses conseils et son encadrement bienveillant tout au long du projet~;
  \item[$\bullet$] \textbf{Nicolas MARILLEAU} pour ses lumières sur le code source de GAMA~;
  \item[$\bullet$] \textbf{Jean-Marie GAUTHIER} pour ses indications techniques précises concernant la configuration de plugin Eclipse.
  \end{enumerate}
}

\setcounter{tocdepth}{1}
\tableofcontents 

\listoffigures{}

\chapter*{Introduction}
\label{intro}
\addcontentsline{toc}{chapter}{Introduction}

\href{https://code.google.com/p/gama-platform/}{\textbf{GAMA}}\footnote{Gis Agent-based Modeling Architecture} est une approche récente de modélisation basée agent et de simulation. Il est développé sous l'égide de l'IRD/UPMC\footnote{Insitut de Recherche pour le Développement et Université Pierre et Marie-Curie} par plusieurs équipes de recherche. GAMA distingue de façon claire les deux aspects de la plate-forme. La modélisation est gérée par le méta-modèle et les simulations sont gérées par le simulation kernel. La philosophie de GAMA est de considérer les agents et l'environnement comme les éléments essentiels du modèle.

GAMA est basée sur Eclipse et permet la création et l'exécution de simulateurs multi-agents dans un langage dédiée : \textbf{GAML}\footnote{GIS and Agent-based Modeling Language}. GAML est utilisé pour la définition du modèle d'implémentation du simulateur. GAML est un langage textuel et utilisable avec Xtext - il est développé comme un projet Eclipse dans le cadre de l' EMF\footnote{Eclipse Modeling Framework}. GAML définit un formalisme général pour définir toutes les entités de base fournies par le méta-modèle GAMA : les agents, les populations, les espèces, l'environnement et le monde.

La création et le développement d'un outil de modélisation et de simulation pour l'étude d'un système complexe, et plus particulièrement pour l'étude de la mobilité géographique, n'est pas une opération simple. Afin de rendre cette technologie accessible au plus grand nombre d'utilisateurs possible, et en particulier aux non-informaticiens, il a été créé un méta-modèle PAML\footnote{Perceptory Agent Modeling Language} basée sur UML permettant une modélisation graphique du système étudié à partir de laquelle sera généré automatiquement le simulateur. L'outil qui permet actuellement de créer les modèles se nomme \href{http ://www.beotic.org/us/index.php}{BeoModeler}. La plate-forme de simulation utilisée dans cet outil est GAMA.

Les travaux de ce projet ont consisté à effectuer une analyse du travail déjà effectué sous BeoModeler : formalismes de modélisation et génération du simulateur. La deuxième phase sera la création de l'environnement de modélisation qui prendra la forme d'un plug-in Eclipse qui sera ajouté à la plate-forme GAMA.

\subsection*{Plan du rapport}

\subsubsection*{Chapitre 1}

Le premier chapitre présente l'objectif du projet, la phase de recherche et d'étude sur la plate-forme GAMA ainsi que le développement d’un plugin Eclipse. Nous présentons la procédure pour l’installation la plate-forme GAMA sur Eclipse. Une fois l’installation réalisée nous nous concentrons sur la création d’un plugin Eclipse.

\subsubsection*{Chapitre 2}

Le seconde chapitre présente le choix d’un outil de modélisation graphique suite à l’analyse de divers outils de modélisation graphique existants. Une fois le choix fait, nous rentrons dans les détails sur l’étude de l’outil de modélisation choisi.

\subsubsection*{Chapitre 3}

Le troisième chapitre présente la création du méta-modèle PAML avec l’outil de modélisation que nous avons choisi dans le chapitre précédent. Nous présentons ensuite tout le processus associé au développement d’un outil de palette personnalisée afin de construire des modèles graphiquement. Nous terminons le chapitre par la création d’un exemple de modèle avec la palette personnalisée.

\subsubsection*{Chapitre 4}

Le quatrième chapitre présente le processus d'intégration de notre contribution dans la plate-forme GAMA. Nous montrons les problèmes rencontrés pour l’intégration. Ensuite nous présentons la solution apportée.\\

Enfin, nous dressons la conclusion du travail effectué durant ce projet et effectuons le bilan des actions menées. Pour finir, nous proposerons différentes perspectives de travail qui permettront d’améliorer et d’enrichir les résultats obtenus.

\chapter{Phase de recherche et d'étude}
\label{recherche}

Nous allons commencer par expliquer en détail l'objectif du projet. Nous verrons ainsi pourquoi il nous a fallu commencer notre travail par une phase d'étude et de documentation sur certains outils.

\section{Objectif du projet}
\label{sec:objectif}

GAMA permet la simulation multi-agents de systèmes géographiques complexes en générant automatiquement un simulateur à partir d'un modèle conforme au méta-modèle PAML. Afin de rendre cette technologie accessible au plus grand nombre d’utilisateurs possible, et en particulier aux non-informaticiens, l'enjeu est de pouvoir réaliser la modélisation à l'aide d'outils graphiques.\\

À l'heure actuelle, l’outil qui permet de créer les modèles de manière graphique se nomme BeoModeler. Cependant le fait d'avoir à utiliser un outil complémentaire non intégré à GAMA, et qui prend en charge uniquement l'aspect de la modélisation graphique entraîne une certaine lourdeur d'utilisation, notamment pour le public visé. L'enjeu du projet est donc de développer un plug-in de modélisation graphique pour GAMA.

Le projet a donc pour but la création d'un environnement de modélisation graphique qui prendra la forme d’un plug-in Eclipse qui devra être intégré à la plate-forme GAMA.\\

Ainsi il nous a fallu tout d'abord étudier GAMA, son fonctionnement et son utilisation. Nous verrons donc les démarches nécessaires pour l'installation de la plate-forme GAMA. Ensuite nous avons étudié le développement d'un plugin Eclipse et des éléments qui permettent son intégration : perspectives, vues\ldots

\section{Installation de GAMA}

La plate-forme GAMA est basée sur Eclipse. Dans cette partie nous allons voir les étapes de  son installation sur Eclipse. Ces étapes sont expliquées de façon très détaillées sur un wiki dédié aux développeurs sur le site de GAMA\footnote{\href{https://code.google.com/p/gama-platform/wiki/DevelopingGuide15}{https://code.google.com/p/gama-platform/wiki/DevelopingGuide15}} :
\begin{itemize}
  \item tout d'abord nous avons téléchargé la version 3.7.2 d'Eclipse Modeling Tools (Indigo). Nous sommes contraints d'utiliser de cette version d'Eclipse, car la version actuelle de la plate-forme GAMA est développée pour la version Indigo d'Eclipse~;
  \item ensuite nous avons installé le plugin Subversive d'Eclipse pour l'utilisation
de SVN ;
\item  finalement nous avons téléchargé le code source de GAMA depuis le site \href{https://gama-platform.googlecode.com/svn}{https://gama-platform.googlecode.com/svn} à l'aide du plugin SVN d'Eclipse.\\
\end{itemize}

Après avoir téléchargé le code source, nous l'avons analysé. L'exécution de la plate-forme GAMA se fait à partir du projet \texttt{msi.gama application}.\\

Une fois que nous disposions des sources, il nous a tout de même fallu régler plusieurs problèmes de compatibilité pour réellement arriver à faire fonctionner GAMA de cette manière. Notamment il nous a fallu un moment pour nous apercevoir que nous n'avions pas la bonne version d'Xtext\footnote{Xtext est un framework pour le développement de langages de programmation spécifiques à des domaines particuliers.} et que cela suffisait à empêcher une exécution correcte de GAMA. C'est Nicolas Marilleau, l'un des développeurs de GAMA, qui nous a aidé à diagnostiquer et résoudre ces problèmes techniques.

Dans l'intervalle, nous avons tout de même pu tester GAMA à partir d'une version exécutable pour étudier son ergonomie et son fonctionnement. Nous avons pu réaliser quelques tests d'utilisation avec des modèles prédéfinis pour mieux comprendre par qui et pourquoi il est utilisé.\\

Puisque notre objectif était de créer un plugin ajoutant des fonctionnalités à GAMA, il nous a fallu étudier le fonctionnement modulaire d'Eclipse et son système de plugin.

%Les figures suivantes \ref{gama1} et \ref{gama2} illustrent l'exécution de la
% plate-forme GAMA.

%\begin{figure}[h!] 
%\centering
%\includegraphics[width=256pt,height=230pt]{gama1.jpg}
%\caption{\label{gama1}Execution de la plate-forme GAMA}
%\end{figure}

%\begin{figure}[h!] 
%\centering
%\includegraphics[width=256pt,height=230pt]{gama2.jpg}
%\caption{\label{gama2}Execution de la plate-forme GAMA}
%\end{figure}


\section{Création et configuration d'un plugin}

\begin{figure}
\centering
\includegraphics[scale=.4]{img/plugin1.jpg}
\caption{\label{plugin1}Création d'un projet de plugin eclipse}
\end{figure}

\label{création plugin}
Afin de créer notre propre plugin, nous avons étudié des tutoriels sur le développement d'un plugin Eclipse. Dans cette partie nous allons décrire la création et la configuration des applications basées sur Eclipse 3.0.\\

Eclipse 3.0 prend en charge la réutilisation de la plate-forme Eclipse pour
créer des applications autonomes basées sur la même technologie que l'IDE Eclipse. À ce stade, le terme Eclipse RCP a été inventé. Eclipse RCP est l'abréviation de
la \textit{plate-forme de Eclipse Rich Client} et indique que la plate-forme
Eclipse est réutilisée comme une base pour créer des applications autonomes riches en fonctionnalités. La plate-forme Eclipse est le plus connu et le plus stable \textbf{IDE} (environnement de développement intégré) pour Java et est à ce titre largement utilisée dans le domaine.\\

Pour créer un plugin Eclipse 
\begin{itemize}
\item tout d'abord on sélectionne \texttt{File / New / Other / plugin Development} dans le menu d'Eclipse. (voir figure \ref{plugin1}) ;
\item ensuite on laisse les paramètres par défaut jusqu'à la troisième page de wizard ;
\item  sur la troisième page de wizard, on sélectionne une template
prédéfinie (voir figure \ref{plugin2}).\\
\end{itemize}

En appuyant sur le bouton \texttt{finish}, tous les fichiers nécessaires sont générés pour la création d'un plugin Eclipse. Le fichier central pour lancer l'application est le fichier \texttt{plugin.xml}, créé dans la racine du dossier de projet. 

\begin{figure} 
\centering
\includegraphics[scale=.4]{img/plugin2.jpg}
\caption{\label{plugin2}Sélection d'une template prédéfinie}
\end{figure}

\section{Perspectives, vues}
\label{perspectives}
Lors du démarrage d'une application Eclipse RCP, une seule fenêtre s'ouvre
contenant le plan de travail (\textit{Workbench}). Le plan de travail est composé de perspectives dont plusieurs peuvent être ouvertes mais une seule est affichée à la fois. Une perspective contient des sous-fenêtres qui peuvent contenir des vues (\textit{views}) et des éditeurs (\textit{editors}). 

\subsection{Création et configuration d'une perspective}
Une perspective est définie par \texttt{org.eclipse.ui.perspectives}.
Pour ajouter une extension d'une perspective dans un plugin, il faut suivre les étapes suivantes :
\begin{enumerate}
  \item Ouvrir le fichier \texttt{plugin.xml}.
  \item Choisir l'onglet \texttt{Extensions} sur ce fichier.
  \item Cliquer sur le bouton \texttt{Add}. 
  \item Dans la fenêtre qui apparaît, on saisit \texttt{org.eclipse.ui.perspectives}.
  \item Sélectionner \texttt{org.eclipse.ui.perspectives} dans la liste et cliquer sur le bouton \texttt{Finish}.
  \item Voici l'extension de la perspective ajoutée .
\end{enumerate}

Nous avons illustré l'ajout d'une extension d'une perspective sur la figure \ref{perspective1}. La numérotation sur la figure correspond aux étapes de l'ajout d'une extension listées ci-dessus.

\begin{figure}
\centering 
\includegraphics[scale=.2]{img/perspective1.jpg}
\caption{\label{perspective1}L'ajout une extension d'une perspective}
\end{figure} 

\paragraph{}
Après avoir ajouté l'extension de la perspective, on clique à droite sur l'extension \texttt{org.eclipse.ui.perspectives}, puis \texttt{New / perspective} et on ajoute une perspective. La configuration de la perspective est faite comme l'indique la figure \ref{perspective2} en remplissant les paramètres \texttt{id, name, class}\ldots

\begin{figure}
\centering 
\includegraphics[scale=.3]{img/perspective2.jpg}
\includegraphics[scale=.3]{img/perspective3.jpg}
\caption{\label{perspective2}L'ajout et la configuration de la
perspective}

\end{figure}
\paragraph{}
Nous devons également ajouter \texttt{org.eclipse.ui.perspectiveExtensions}, une extension supplémentaire pour pouvoir relier les différents composants (les vues, les editeurs) à une même perspective dans le plugin. De la même façon que pour l'ajout d'une perspective on ajoute une extension de \texttt{perspectiveExtensions}. Pour relier \texttt{perspectiveExtensions} à la perspective, on attribue à la valeur \texttt{id} de \texttt{perspectiveExtensions} la même que celle de la perspective (voir figure \ref{perspective4}).\\

\begin{figure}
\centering 
\includegraphics[scale=.5]{img/perspective4.jpg}
\caption{\label{perspective4}La configuration de la perspectiveExtensions}
\end{figure}

\subsection{Intégration d'une vue dans une perspective}
Comme nous l'avons déjà dit, une perspective est composée de sous-fenêtres qui peuvent être de deux types :
\begin{itemize}
  \item les vues ;
  \item les éditeurs.\\
\end{itemize}

Une \textbf{vue} permet de visualiser et de sélectionner des éléments. Il n'est pas possible d'afficher plusieurs fois la même vue dans une même perspective. Par contre plusieurs vues différentes peuvent être rassemblées dans une même perspective.\\

Un \textbf{éditeur} permet de visualiser mais aussi de modifier le contenu d'un élément. Un éditeur peut contenir plusieurs éléments, chacun étant identifié par un onglet.\\

À titre d'exemple nous allons ajouter une vue à la perspective qui a été créé
ci-dessus. Tout d'abord on ajoute une vue via \texttt{org.eclipse.ui.views}.
Ensuite on configure les paramètres de la vue ajoutée (voir la figure
\ref{vue5}). Comme il apparaît dans l'example, il faut créer la classe de la
vue. C'est dans la classe que l'on spécifie les éléments qui décrivent la vue.\\

\begin{figure}
\centering 
\includegraphics[scale=.3]{img/vue5.jpg} 
\caption{\label{vue5}La configuration de la vue}
\end{figure}

Enfin nous ajoutons dans l'extension \texttt{perspectiveExtensions} la vue créée ci-dessus  (voir la figure \ref{vue6}). Le résultat que nous obtenons à la fin est présenté à la figure \ref{resultat8}.


\begin{figure} 
\centering 
\includegraphics[scale=.3]{img/vue6.jpg}
\includegraphics[scale=.3]{img/vue7.jpg}  
\caption{\label{vue6} Ajout d'une vue dans la \texttt{perspectiveExtensions}}
\end{figure} 

\begin{figure}
\centering 
\includegraphics[scale=.5]{img/resultat8.jpg} 
\caption{\label{resultat8} Le resultat}
\end{figure} 


\chapter{Choix d'un outil de modélisation}
\label{choix}

Après avoir étudié la création de perspective et de plugins dans Eclipse, nous aurions pu envisager de construire nous-même à partir de zéro une perspective contenant un environnement de modélisation graphique que nous aurions entièrement développé. Cependant ce travail aurait été inutilement long et fastidieux, car des outils existent déjà pour faire de la modélisation graphique. Il nous a alors fallu étudier les différentes solutions pour choisir l'outil le plus adapté à nos besoins, puis apprendre à l'utiliser.

\section{Quelques outils de modélisation graphique existants}
\label{sec:outils}
 
Plusieurs outils permettent de faire de la modélisation graphique mais nous avions ici la contrainte de la possibilité d'intégration dans Eclipse. Il nous a donc fallu comparer les deux solutions principales existantes pour faire de la modélisation graphique au sein d'Eclipse.

\subsection{Outils au sein d'EMF}

Le projet \textbf{EMF} (Eclipse Modeling Framework)\footnote{\href{http://www.eclipse.org/modeling/emf/}{http://www.eclipse.org/modeling/emf/}} est un framework qui fournit de nombreux outils pour faire de la modélisation. On peut citer par exemple, et sans être exhaustif :
\begin{itemize}
\item la définition de modèles et de méta-modèles sous forme textuelle ou graphique en utilisant le format \textbf{Ecore} ;
\item l'utilisation du langage de contraintes \textbf{OCL} ;
\item la génération de modèles à partir de méta-modèles ;
\item la transformation automatique de modèles\footnote{ATL} ;
\item la génération automatique de code à partir de modèle\footnote{Acceleo}\ldots\\
\end{itemize}

Partie intégrante du projet Eclipse depuis longtemps, ce framework est aujourd'hui de fait un standard pour la modélisation. Au sein d'EMF existe le composant \textbf{Ecore Tools} qui a entre autres objectifs de permettre la création et l'édition de modèles au format Ecore à l'aide d'un éditeur graphique (qui travaille sur des diagrammes au format \textit{ecorediag} qui sont en fait une vue d'un fichier \textit{ecore} contenant le modèle).\\

Nous avions déjà une petite expérience de ces outils pour les avoir utilisés dans le cadre d'un projet en IDM\footnote{Ingénierie Dirigée par les Modèles}. Nous avons donc pu lister ses avantages et ses inconvénients de notre point de vue dans l'optique de l'utilisation particulière que nous voulions en faire.\\

\noindent \textbf{Avantages :}
\begin{itemize}
\item bonne intégration dans Eclipse car EMF est un projet Eclipse de longue date~;
\item maturité du framework~;
\item existence de nombreux outils complémentaires dans EMF permettant d'envisager des évolutions de l'outil développé~;
\item utilisation très répandue dans le domaine de la modélisation~;
\item existence d'une importante communauté d'utilisateurs.\\
\end{itemize}

\noindent \textbf{Inconvénients :}
\begin{itemize}
\item difficultés d'installation et de configuration liées au nombre et à la variété des plugins fournis par EMF~;
\item relative lourdeur d'utilisation de l'outil graphique (ce point est d'autant plus important que l'outil que nous développons sera amené à être utilisé par des non-informaticiens qui sont peu familiers de la modélisation)~;
\item rendu graphique pas forcément très satisfaisant et prise en main assez difficile pour l'utilisateur.
\end{itemize}

\subsection{Papyrus}

\textbf{Papyrus}\footnote{\href{http://www.eclipse.org/papyrus/}{http://www.eclipse.org/papyrus/}} est un outil d'édition graphique qui fournit un environnement de travail adapté à de nombreux langages de modélisation. Développé initialement au sein du CEA, c'est maintenant officiellement un projet Eclipse depuis $2008$. Il possède des outils d'édition graphique pour travailler entre autres avec UML et SysML. 

Une des caractéristiques intéressantes de Papyrus est de fournir des mécanismes de personnalisation de la plupart de ses outils : explorateur de modèle, éditeur de diagramme, éditeur de propriétés\ldots\\

\noindent \textbf{Avantages :}
\begin{itemize}
\item simplicité de l'installation\footnote{Encore une fois un point important pour la facilité d'utilisation de l'outil par le plus grand nombre} \og monobloc\fg~au sein d'Eclipse d'une version de Papyrus spécialement adaptée à notre version de travail d'Eclipse\footnote{Eclipse 3.8 Indigo, version imposée par la version de GAMA}~;
\item bonne qualité de rendu de l'outil graphique~;
\item prise en main simple et intuitive pour l'utilisateur de l'outil de modélisation graphique~;
\item inclusion d'outils spécifiques -- perspective Papyrus, palettes -- permettant d'envisager une bonne intégration dans GAMA.\\
\end{itemize}

\noindent \textbf{Inconvénients :}
\begin{itemize}
\item semble moins largement répandu~;
\item plus grande difficulté à trouver des exemples et de la documentation.\\
\end{itemize}

Après avoir mis en balance les avantages et inconvénients des deux solutions par rapport à nos besoins spécifiques, nous avons finalement pu faire un choix pertinent dans l'optique de l'intégration dans GAMA.

\section{Choix de papyrus}
\label{sec:choix_papyrus}

Malgré les nombreuses qualités de l'environnement de modélisation graphique d'EMF, nous avons préféré opter pour Papyrus qui nous a semblé offrir de meilleures possibilités graphiques. D'autre part, les facilités d'intégration de Papyrus dans un autre projet sont intéressantes, soit par le biais d'une perspective Papyrus, soit via l'utilisation sous forme de plugin.\\

Autre critère de choix, l'objectif de ce projet est de fournir un environnement de modélisation graphique à destination d'utilisateurs qui ne sont pas forcément des experts de la modélisation. Ainsi l'outil doit-il être simple et efficace, tant dans son installation que dans son utilisation, en particulier au niveau de l'ergonomie et du rendu graphique. Et c'est le cas de Papyrus.\\

Une fois le choix de Papyrus fait pour les raisons évoquées ci-dessus, il nous a fallu étudier l'outil en lui-même. Son utilisation d'une part et la structure de son développement pour identifier les éléments de Papyrus que nous pourrions utiliser ou adapter.

\section{Étude des sources de Papyrus}
\label{sec:sources}

\newcommand{\scalepapyrus}{.45}
\begin{figure}
  \includegraphics[scale=\scalepapyrus]{img/1.png}
  \includegraphics[scale=\scalepapyrus]{img/3.png}
  \includegraphics[scale=\scalepapyrus]{img/2.png}
  \includegraphics[scale=\scalepapyrus]{img/4.png}
  \caption{Aperçu de la structure du projet Papyrus}
  \label{fig:structurepapyrus}
\end{figure}

Notre cahier des charges était d'intégrer l'outil de modélisation à GAMA -- idéalement à travers une perspective dédiée -- en personnalisant les outils de modélisation graphique pour les adapter au méta-modèle PAML. 

Puisque les deux outils (perspective et palette de modélisation graphique) sont fournis par Papyrus, notre première idée a été d'essayer de ne réutiliser que la part de Papyrus qui nous intéresse en l'adaptant. Ainsi, nous n'aurions utilisé qu'une partie du code du projet Papyrus que nous aurions modifiée pour ne retenir que les outils dont nous avions besoin. Par exemple, la perspective Papyrus aurait été adaptée pour ne retenir que les vues et les types de diagrammes qui nous sont utiles et la palette de modélisation graphique aurait été adaptée au méta-modèle PAML.\\

Nous avons donc commencé à analyser la structure des sources du projet Papyrus à partir du dépôt SVN officiel\footnote{\href{http://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/}{http://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/}}. Mais cette idée de réutilisation et d'adaptation à partir du code s'est vite révélée très complexe à mettre en \oe uvre pour plusieurs raisons~:
\begin{itemize}
\item le projet Papyrus étant lui-même complexe, il est long et fastidieux d'en comprendre la structure (près de $250$ packages dont la figure \ref{fig:structurepapyrus} donne un petit aperçu)~;
\item le projet étant découpé de façon très modulaire en de nombreux plugins, il est difficile voire irréaliste d'en extraire ou d'en modifier une partie en espérant conserver une cohérence d'ensemble.\\
\end{itemize}

D'autre part les fonctionnalités de Papyrus répondent finalement plutôt bien à nos besoins en l'état~:
\begin{itemize}
\item Papyrus dispose d'une perspective dédiée au sein de laquelle se fait la modélisation graphique~;
\item il existe au sein de Papyrus un mécanisme de création de palette de modélisation graphique.\\
\end{itemize}

Pour finir, ce choix paraît également plus pertinent du point de vue de la maintenance et de l'évolutivité de l'outil développé. En effet \og extraire\fg~une partie de Papyrus et la modifier figera l'outil obtenu, ou rendra très difficile son évolution. Tandis que s'appuyer sur l'ensemble des fonctionnalités de Papyrus permettra d'envisager plus facilement les évolutions futures~: notamment lors d'une évolution de GAMA imposant un changement de version d'Eclipse, il suffira d'adapter la version de Papyrus utilisée.

\chapter{Méta-modèle et configuration du plugin}
\label{metamodele}

Après avoir fait le choix de l'outil Papyrus, il nous a fallu aborder la partie plus directement liée à GAMA. Tout d'abord intégrer le méta-modèle PAML dans Papyrus. Ensuite l'exploiter pour obtenir une palette graphique permettant la construction des objets dont les types sont décrits dans le méta-modèle. Et finalement configurer un plugin embarquant cette palette pour obtenir un environnement graphique de création de modèles conformes au méta-modèle PAML (voir figure \ref{fig:metamodel_aml}).

\begin{figure}
  \centering
  \includegraphics[scale=.35]{img/metaModeleAMLPerceptory.png}
  \caption{Méta-modèle PAML}
  \label{fig:metamodel_aml}
\end{figure}

\section{Création du méta-modèle avec Papyrus}
\label{sec:metamodel}

L'outil que nous devons proposer doit permettre de construire graphiquement des modèles conformes au méta-modèle PAML. Afin d'assurer la conformité des modèles obtenus, il nous faut spécifier le méta-modèle utilisé, et donc le construire dans Papyrus.

Au sein de Papyrus, la palette de création graphique par défaut s'intitule \texttt{PapyrusUMLProfileDiagram Standard Palette}. Elle met à disposition tous les éléments nécessaires pour construire un modèle ou un méta-modèle basé sur UML. Ainsi, le fait que Papyrus intègre UML -- dont est issu le méta-modèle PAML -- simplifie la création du méta-modèle dans Papyrus.\\

Disposer du méta-modèle PAML dans Papyrus nous permettra de créer une palette personnalisée reprenant les stéréotypes du méta-modèle. D'autre part, cela ouvre des perspectives intéressantes de modélisation :
\begin{itemize}
\item en cas d'évolution du méta-modèle, il sera facile de s'appuyer sur le travail déjà fait pour simplement le modifier ;
\item disposer du méta-modèle défini au sein d'Eclipse permet d'envisager par la suite l'utilisation des outils de modélisation fournis par EMF ;
\item en particulier on peut générer un fichier \texttt{genmodel} qui pourrait servir à construire des modèles de manière \og assistée\fg~avec un générateur de modèle\footnote{Cette façon de faire serait finalement un compromis entre modélisation purement textuelle difficilement accessible à un utilisateur lambda et un outil de modélisation purement graphique comme celui que nous mettons en place.} (par exemple EMF Facet).\\
\end{itemize}

Il est à noter que la palette Papyrus obtenue par la suite repose simplement sur un fichier XML que l'on peut alors utiliser indépendamment du méta-modèle construit. Vu comme cela, la création du méta-modèle ne semble pas indispensable et on aurait pu imaginer d'éditer simplement le fichier XML. Outre que cette solution ne serait pas très \og propre\fg~du point de vue de la modélisation, nous serions passé à côté des avantages du méta-modèle décrit ci-dessus.\\

\begin{figure}
  \centering
  \includegraphics[scale=.45]{img/metamodelepapyrus.png}
  \caption{Description du méta-modèle sous Papyrus}
  \label{fig:metamodel_papyrus}
\end{figure}

En pratique, nous avons eu besoin de définir les stéréotypes de tous les objets qui pourront être présents dans un modèle PAML conforme. Ces entités seront basé sur l'élément \texttt{Class} d'UML. Nous définissons donc dans Papyrus tous les stéréotypes utiles (figure \ref{fig:metamodel_papyrus}) :
\begin{itemize}
\item \texttt{Environment} ;
\item \texttt{Ressource} ;
\item \texttt{Situated Agent} ;
\item \texttt{Behavior} ;
\item \texttt{Groupe type} ;
\item \texttt{Role type} ;
\item \texttt{Agent type} ;
\item \texttt{Point} ;
\item \texttt{Arc} ;
\item \texttt{Polygon}.\\
\end{itemize}

Tous ces éléments héritent du stéréotype \texttt{metaclass} d'UML. Il suffit ensuite de définir toutes les associations nécessaires entre les éléments avec leurs multiplicités.\\

Les stéréotypes définis ici nous permettront de typer les éléments d'un modèle conforme. Ainsi, le méta-modèle obtenu rend possible la création d'une palette personnalisée dans laquelle on retrouvera tous les éléments utiles pour définir un modèle dans GAMA. 

On a déjà vu que la création dans Papyrus de ce méta-modèle pourrait trouver d'autres applications que la simple création de notre palette, même si ce n'est pas le cas pour l'instant. En particulier par exemple les associations définies ici au niveau du méta-modèle sont indispensables à sa cohérence mais elles n'auront aucune incidence sur la palette graphique que nous allons créer.\\

Une fois le méta-modèle PAML construit dans Papyrus, il nous est possible de créer une palette de modélisation graphique personnalisée.

\section{Création de palette personnalisée}
\label{sec:palette}

Une fois le méta-modèle défini, on utilise l'interface de Papyrus prévue pour la personnalisation de la palette graphique.

\begin{figure}
  \centering
  \includegraphics[scale=.3]{img/palette_customize.png}
  \caption{Création d'un élément possédant un stéréotype prédéfini}
  \label{fig:palette_customize}
\end{figure}

\begin{enumerate}
\item Se placer dans la perspective Papyrus.
\item Choisir \textit{customize} dans le menu contextuel de la palette courante.
\item Dans la liste des palettes disponibles, choisir l'icône marqué d'un $+$ (\textit{create a new local palette}).
\item Choisir un nom pour la palette puis par exemple pour créer une nouvelle entrée \texttt{Environment} (figure \ref{fig:palette_customize}) :
  \begin{itemize}
  \item choisir d'ajouter un objet \texttt{Class} à partir de la zone \textit{Available Tools}, en choisissant \textit{UML tools} ;
  \item remplir convenablement les champs \textit{Name} et \textit{Description}. Le champ \textit{Extended Too} doit contenir \textit{org.eclipse.uml2.uml.Class} ;
  \item dans \textit{Aspect Actions}, choisir l'icône marqué d'un $+$ puis \textit{Set list of applied stereotypes} ;
  \item dans la partie \textit{Stereotypes to apply}, cliquer sur l'icône marqué d'un $+$ pour afficher la liste des stéreotypes définis dans le méta-modèle. Choisir le stéréotype voulu (ici \texttt{profile::Environment}).
  \end{itemize}
\item Ajouter pour finir les éléments supplémentaires du méta-modèle pour lesquels aucune personnalisation n'est nécessaire : \texttt{Dependency}, \texttt{Association}\ldots
\item Définir des icônes personnalisés dans la rubrique \textit{Icon}\footnote{Comme la palette peut ensuite être utilisée dans un autre projet, on peut aussi comme nous l'avons fait modifier plus tard les champs \texttt{iconpath} dans le fichier XML.}.\\
\end{enumerate}

\begin{figure}
  \begin{tabular}{p{.5\linewidth}p{.5\linewidth}}
    \includegraphics[scale=.3]{img/profile.png}
    &
    \includegraphics[scale=.3]{img/profile2.png}
  \end{tabular}
  \caption{Configuration d'un nouveau modèle Papyrus}
  \label{fig:profile}
\end{figure}

Un point de détail technique qui nous a posé problème au début est d'arriver à \og récupérer\fg~les stéréotypes décrits par le méta-modèle PAML lorsque nous avons voulu personnaliser une palette dans un nouveau modèle Papyrus. En effet nous ne disposions par défaut que des \textit{UML tools} dans lesquels nous ne retrouvions pas nos stéréotypes \texttt{Environment}, \texttt{Agent}\ldots

Il s'est avéré qu'un nouveau modèle Papyrus (décrit dans un fichier \texttt{model.di}) est par défaut \textbf{basé sur UML}. Ce choix ne peut pas être modifié par la suite. Si on souhaite pouvoir utiliser les éléments du méta-modèle, il faut donc effectuer la personnalisation de la palette dans un modèle Papyrus correctement configuré (voir figure \ref{fig:profile}) :
\begin{itemize}
\item on doit d'abord choisir \texttt{Profile} (le fichier contenant le modèle est alors renommé en \texttt{model.profile.di}) ;
\item il faut ensuite cocher \texttt{UML Profile Diagram} dans la zone \textit{Select a Diagram Kind}.\\
\end{itemize}

\begin{figure}
  \centering
  \includegraphics[scale=.5]{img/palette.png}
  \caption{Palette personnalisée conforme au méta-modèle}
  \label{fig:palette}
\end{figure}

La méthode utilisée ici au sein de Papyrus n'est pas seulement limitée au cadre de notre projet. Si Papyrus propose nativement un support des diagrammes SysML et UML, on peut imaginer comme nous l'avons fait pour PAML créer au sein de Papyrus des environnements de modélisation basé sur n'importe quel méta-modèle.

Par ailleurs, on remarque que la palette personnalisée obtenue (voir figure \ref{fig:palette}) se base finalement largement sur le méta-modèle UML, seul le stéréotype des éléments est adapté par rapport au méta-modèle PAML.\\

La palette correspondante au méta-modèle PAML est maintenant crée. Il nous faut, pour pouvoir l'utiliser en situation, l'inclure dans un plugin Eclipse qui lui-même permettra ensuite l'intégration dans GAMA.

\section{Configuration d'un plugin contenant la palette}
\label{sec:config}

Une fois que le méta-modèle PAML est construit, il nous faut maintenant gérer les configurations sur le projet plugin Eclipse afin de pouvoir récupérer le méta-modèle dans le plugin. Tout d’abord nous devons définir les dépendances du plugin. On se place sur l’onglet \texttt{Dependencies} dans le fichier \texttt{plugin.xml}. Ensuite on
ajoute les dépendances suivantes en cliquant sur le bouton \texttt{Add} dans l’onglet
\texttt{Dependencies} : \\

\begin{itemize}
  \item \texttt{org.eclipse.emf.ecore} 
  \item \texttt{org.eclipse.emf.ecore.xmi}
  \item \texttt{org.eclipse.uml2.uml} 
  \item \texttt{org.eclipse.papyrus.extensionpoints.uml2} 
  \item \texttt{org.eclipse.core.runtime}
  \item \texttt{org.eclipse.ui}
  \item \texttt{org.eclipse.papyrus.diagram.common}
\end{itemize} 

\paragraph{} 
Maintenant on peut ajouter les extensions suivantes dans le projet. On doit
également configurer chaque extension ajoutée. On va lister des paramètres à définir pour chaque extension.

\begin{enumerate}
  \item \texttt{org.eclipse.emf.ecore.generated\_package} voir la figure \ref{extension1} pour la configuration
  
  \begin{itemize} 
    \item \texttt{uri} : \texttt{http://www.femto-st.fr/disc/GamaModeling} 
    \item \texttt{class} : \texttt{profile.ProfilePackage} (la création de la classe)
    \item \texttt{genModel} : \texttt{MetaModel/model.profile.genmodel} (la définition du chemin pour le fichier \texttt{genModel})
  \end{itemize} 
  
  \item \texttt{org.eclipse.emf.ecore.extension\_parser} (voir la figure
  \ref{extension1})
	
	\begin{itemize}
	  \item	\texttt{type} : \texttt{GAMA}
	  \item	\texttt{class} : \texttt{profile.util.ProfileResourceFactoryImpl} (la création de la classe)
	\end{itemize}
	
	\item \texttt{org.eclipse.emf.ecore.uri\_mapping} %(voir la figure
	% \ref{extension1})
	
		\begin{itemize}
	  		\item \texttt{source} : \texttt{pathmap://GAMA\_MODELING/}
	  		\item \texttt{target} :
	  		\texttt{platform:/plugin/projet.master.gama.modelisation/MetaModel/} (le chemin pour \texttt{GAMA\_MODELING})
		\end{itemize}
	
	\item \texttt{org.eclipse.papyrus.extensionpoints.uml2.UMLProfile } %(voir la
	%figure \ref{extension2})
	
	\begin{itemize}
	  \item	\texttt{name} : \texttt{GamaModeling}
	  \item	\texttt{path} : \texttt{pathmap://GAMA\_MODELING/model.profile.uml} (le chemin pour \texttt{model.profile.uml}, on va définir plus tard le chemin \texttt{GAMA\_MODELING})
	\end{itemize}
			
	\item \texttt{org.eclipse.papyrus.diagram.common.paletteDefinition} %(voir la
	%figure \ref{extension2})
		\begin{itemize}
	  		\item \texttt{name} : \texttt{GamaPalette}.
	  		\item \texttt{ID} : \texttt{GP}.
	  		\item \texttt{path} : \texttt{Palette/GamaPalette.xml}.
	  		\item \texttt{class} :
	  		\texttt{org.eclipse.papyrus.diagram.common.service.PluginPaletteProvider} (la création de la classe)
		\end{itemize} 
\end{enumerate}


\begin{figure}
  \centering
  \includegraphics[scale=.5]{img/extension2.jpg}
  %\includegraphics[scale=.5]{img/extension4.jpg}
  \includegraphics[scale=.5]{img/extension1.jpg}
  \caption{\label{extension1}La configuration des extensions}
\end{figure} 

%\begin{figure}
  %\centering
  %\includegraphics[scale=.5]{img/extension3.jpg}
  %\includegraphics[scale=.5]{img/extension5.jpg}
  %\caption{\label{extension2}La configuration des extensions}
%\end{figure} 


\section{Exemple de modèle construit graphiquement}
\label{sec:modele}

Nous allons utiliser l'exemple simple reproduit à la figure \ref{fig:modelexample} afin d'illustrer le fait qu'à l'issue d'une modélisation graphique avec l'outil développé, nous disposons bien (dans un fichier XMI) de toutes les informations nécessaires à l'utilisation ultérieure du modèle dans GAMA.\\

Une modélisation graphique réalisée avec notre palette personnalisée repose comme pour tous les modèles Papyrus sur trois fichiers d'extensions respectives \texttt{di}, \texttt{notation} et \texttt{uml} :
\begin{enumerate}
\item \texttt{model.di} est en fait un fichier XML comprenant quelques indications et des liens vers les autres fichiers. C'est ce fichier qui est interprété par \texttt{Papyrus Editor Core} qui génère la représentation graphique.
\item \texttt{model.notation} contient tous les éléments nécessaires à la mise en forme de la représentation graphique.
\item \texttt{model.uml} contient une description du modèle indépendante de toute représentation graphique. C'est ce fichier qui va nous permettre de retrouver tous les éléments qui ont été construits graphiquement avec la palette.\\
\end{enumerate}

\begin{figure}
  \centering
  \includegraphics[scale=.4]{img/modelexample2.jpg} 
  \caption{Exemple de modèle}
  \label{fig:modelexample}
\end{figure}

Dans la figure \ref{fig:modelexample}, intéressons-nous à l'élément \texttt{Ville} de type \texttt{Environment}. La figure \ref{fig:modelxml} présente des extraits du fichier \texttt{model.uml}, dans lesquels nous retrouvons toutes les informations nécessaires à la description du modèle :

\begin{enumerate}
\item[$\bullet$] Une balise de type \texttt{xmi:type="uml:Class"} décrit effectivement l'élément \texttt{Ville}.
\item[$\bullet$] On retrouve dans des balises \texttt{ownedAttribute} la description des attributs de \texttt{Ville} : \texttt{nb\_people}, \texttt{finTravail}\ldots
\item[$\bullet$] Toutes les informations décrivant l'association entre \texttt{Ville} et \texttt{Bati} sont détaillées dans une balise \texttt{xmi:type="uml:Association"}~: type d'association, multiplicités, nom et identifiant des éléments concernés\ldots
\end{enumerate}

\newcommand*{\fvtextcolor}[2]{\textcolor{#1}{#2}}

\begin{figure}
  \centering
\begin{Verbatim}[fontsize=\footnotesize, frame=single, commandchars=\\\~\%]
 <packagedElement xmi:type="uml:Class" 
		xmi:id="_LwSBEIqoEeOMXIVnjrfxjA" 
		\fvtextcolor~red%~name="Ville"%
		clientDependency="_TXLuwIqtEeOMXIVnjrfxjA">
      <ownedAttribute xmi:id="_NwuO0IqoEeOMXIVnjrfxjA" 
		\fvtextcolor~green%~name="nb_people"%>		
        <type xmi:type="uml:PrimitiveType" 
		href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.
		library.uml#Integer"/>
      </ownedAttribute>
      <ownedAttribute xmi:id="_VAb90IqoEeOMXIVnjrfxjA" 
		name="debutTravail">
        <type xmi:type="uml:PrimitiveType" 
		href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.
		library.uml#Integer"/>
      </ownedAttribute>
      <ownedAttribute xmi:id="_Zu8UUIqoEeOMXIVnjrfxjA" 
		\fvtextcolor~blue%~name="finTravail"%>		
        <type xmi:type="uml:PrimitiveType" 
		href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.
		library.uml#Integer"/>
      </ownedAttribute>
      <ownedAttribute xmi:id="_d_PE0IqoEeOMXIVnjrfxjA" 
		name="minSpeed">
        <type xmi:type="uml:PrimitiveType"  
		href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.
		library.uml#Integer"/>
      </ownedAttribute>
      <ownedAttribute xmi:id="_hxcyMIqoEeOMXIVnjrfxjA" name="maxSpeed">
        <type xmi:type="uml:PrimitiveType" 
        href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.
        library.uml#Integer"/>
      </ownedAttribute>
      <ownedAttribute xmi:id="_lJnn4IqoEeOMXIVnjrfxjA" 
		name="heure">				
        <type xmi:type="uml:PrimitiveType" 
        href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.
        library.uml#Integer"/>
      </ownedAttribute> 
    </packagedElement>
\end{Verbatim}
  \caption{Fichier XMI obtenu}
  \label{fig:modelxml}
\end{figure}

\chapter{Intégration dans GAMA}
\label{integration}

Une fois la palette personnalisée disponible et son fonctionnement testé en lançant notre plugin en tant qu'application Eclipse autonome, il nous faut maintenant arriver à intégrer cet outil au sein de GAMA. L'idée est de fournir les ajouts de fonctionnalités par l'intermédiaire de notre plugin en touchant le moins possible -- idéalement pas du tout -- au code de GAMA à proprement parler. Ainsi notre contribution serait simplement additionnelle et sans aucune incidence sur le logiciel existant.

\section{Liaison du plugin avec GAMA}
\label{sec:liaison}

Pour que notre travail s'intègre au mieux, il est souhaitable de n'avoir à modifier que le strict minimum au niveau du code de GAMA proprement dit. Quoi qu'il en soit, il est nécessaire que GAMA \og connaisse\fg~notre plugin qui va de son côté fournir le service de modélisation graphique.\\

Le lancement de GAMA à partir de ses sources se fait au niveau du package \texttt{msi.gama.application}, via le fichier \texttt{gama1.6.product} (onglet \textit{Overview} puis \textit{Launch an Eclipse application}). C'est donc ce fichier qui contient les informations de configuration du plugin \og principal\fg~qui lance le RCP Eclipse. 

Nous avons donc créé notre plugin \texttt{projet.master.gama.modelisation} dans l'arborescence des sources de GAMA pour ensuite inclure une dépendance dans GAMA :
\begin{itemize}
\item ouvrir le fichier \texttt{gama1.6.product} puis se placer dans l'onglet \textit{Dependencies}~;
\item choisir \texttt{Add} pour trouver \texttt{projet.master.gama.modelisation} et l'ajouter aux dépendances de \texttt{msi.gama.application}.\\
\end{itemize}

D'autre part il est nécessaire que les fonctionnalités de Papyrus soient disponibles au sein de GAMA. Notre première façon de procéder a été d'inclure comme dépendances les plugins de la forme \texttt{org.eclipse.papyrus.*} dans GAMA de la même façon que notre plugin. Évidemment l'idéal aurait été que l'essentiel de cette configuration ne se face qu'au travers de notre plugin. Nous avons donc par la suite essayé de supprimer ces dépendances à Papyrus dans GAMA pour les ajouter dans notre plugin. Mais cette façon de faire n'a pas fonctionné et il nous a donc fallu conserver les références à Papyrus dans les dépendances de GAMA.\\

Ces opérations sur les dépendances de GAMA constituaient vraiment le strict minimum pour espérer inclure les fonctionnalités de notre plugin au sein de GAMA. Il était cependant un peu optimiste de penser qu'elles seraient suffisantes.

\section{Problèmes rencontrés pour l'intégration}
\label{sec:problèmes}

Nous pensions au départ qu'il suffirait que le fichier \texttt{gama1.6.product} fasse appel à notre plugin pour pouvoir disposer de ses fonctionnalités au sein de GAMA, dans une perspective Papyrus. Cette solution nous aurait permis de réutiliser au maximum les fonctionnalités existantes de Papyrus, seule la palette classique étant remplacée par la palette de modélisation graphique que nous avons crée. En particulier, il aurait suffi dans GAMA de choisir une perspective Papyrus pour se retrouver dans un contexte de modélisation graphique.

Malheureusement, en l'état, le lien n'était pas possible à faire entre une perspective Papyrus ouverte dans GAMA et la palette présente dans notre plugin. Ainsi l'utilisation directe de la perspective Papyrus ne permettait pas une intégration des fonctionnalités apportées par notre plugin.\\

Après avoir buté assez longtemps sur ce problème d'intégration, nous avons pu nous adresser à Nicolas Marilleau, l'un des développeurs de GAMA. Il nous a indiqué que pour lui la meilleure façon de faire du point de vue de l'intégration était de fournir nous-même via notre plugin une perspective dédiée à la modélisation graphique. Cette perspective devait donc fournir toutes les vues nécessaires, entre autres celle contenant notre palette. Il a pu également nous fournir quelques indications sur le fonctionnement de GAMA vis-à-vis des perspectives spécifiques utilisées, ce qui nous a simplifié la tâche pour faire le lien dans GAMA avec une perspective définie dans notre plugin.\\

Pour faciliter l'intégration d'une perspective dédiée à GAMA, il existe un mécanisme qui permet de scanner toutes les perspectives fournies par les plugins présents dans ses dépendances. Dans le package \texttt{msi.gama.gui.swt}, la classe \texttt{SwtGui.java} fournit une méthode \texttt{loadPerspectives}.

Cette méthode permet :
\begin{itemize}
\item de récupérer dans l'ensemble des extensions les perspectives ayant été définies en passant par \texttt{org.eclipse.ui.perspectives} ;
\item d'itérer sur les perspectives en extrayant des informations ;
\item de filtrer celles qui ont été construites spécifiquement pour GAMA avec le test \texttt{pluginID.contains("msi.gama")}. Et dans ce cas de lier à un objet \texttt{perspectiveClasses} la classe définissant la perspective au sein de l'extension (\texttt{cl.loadClass(pluginClass)}).\\
\end{itemize}

Cette méthode nous assure qu'une perspective définie dans notre plugin sera correctement intégrée dans GAMA dès le chargement. Pour cela, il nous a tout de même fallu préfixer l'identifiant de notre plugin par \texttt{msi.gama} comme le suggère le test effectué dans la méthode.\\

Une fois ces éléments connus, il nous reste à construire dans notre plugin une perspective personnalisée qui sera accessible dans GAMA pour fournir les outils de modélisation graphique. Cette perspective se base bien sûr sur Papyrus, en incluant certaines des vues prédéfinies par Papyrus.

\begin{figure}
  \centering
\begin{Verbatim}[fontsize=\scriptsize, frame=single]
public final boolean loadPerspectives() {
   if ( !perspectiveClasses.isEmpty() ) { return true; }

   final IConfigurationElement[] config =
   Platform.getExtensionRegistry().getConfigurationElementsFor("org.eclipse.ui.perspectives");
   for ( final IConfigurationElement e : config ) {
      final String pluginID = e.getAttribute("id");
      final String pluginClass = e.getAttribute("class");
      final String pluginName = e.getContributor().getName();
      // Check if is a gama perspective...
      if ( pluginID.contains("msi.gama") ) {
         final ClassLoader cl =
         GamaClassLoader.getInstance().addBundle(Platform.getBundle(pluginName));
         try {
            perspectiveClasses.put(pluginID, cl.loadClass(pluginClass));
         } catch (final ClassNotFoundException e1) {
            e1.printStackTrace();
         }
         System.out.println("Gama perspective " + pluginID + " is loaded");
      }
   } 

   return false; // openPerspective(I);
}
\end{Verbatim}
  \caption{Méthode \texttt{loadPerspective}}
  \label{fig:loadPerspective}
\end{figure}

\section{Construction et intégration d'une perspective personnalisée}
\label{sec:perspective}


\begin{figure}
  \centering
  \includegraphics[scale=.5]{img/palView.jpg}
  \caption{\label{palette}Choix parmi la liste de vues prédefinies}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[scale=.5]{img/graphmodel.png}
  \caption{\label{GraphicalModeling}Sélectionner GraphicalModelingPerspective}
\end{figure}

Dans la partie précédente, nous avons présenté les problèmes rencontrés pour
l'intégration de notre projet dans le plugin GAMA. 
Pour définir les vues dont nous aurions besoin pour notre propre perspective, tout d'abord on a listé toutes les vues qui se trouvent dans la perspective
Papyrus.\\
Voici ces vues :
\begin{itemize}
  \item \textit{Project Explorer} -- la vue d'explorer de projet ;
  \item \textit{Model Explorer} -- la vue d'explorer de modèle ;
  \item \textit{Content Outline} -- la vue de sortie ;
  \item \textit{PropertySheet} -- la vue propriétés ;
  \item \textit{Palette view} -- la vue de la palette.\\
\end{itemize}

 Après avoir défini les vues nous avons créé notre propre perspective en choisissant comme \texttt{id} : \texttt{msi.gama.GraphicalModelingPerspective} (voir section \ref{sec:problèmes} pour des explications sur ce choix) et comme nom \texttt{GraphicalModelingPerspective}.
%Nous étions obligé de commencer se nommer avec \texttt{msi.gama}, car le plugin GAMA ne permet que l'intégration des perspectives qui commence par \texttt{msi.gama}. Voici le bout de code que nous avons trouvé dans le plugin GAMA%\ref{loadPerspective}. 
%\begin{figure}
 % \centering
  %\includegraphics[scale=.5]{img/code.jpg} 
  %\caption{\label{loadPerspective}Le bout de code pour gérer l'intégration des
  %perspectives}
%\end{figure}

La prochaine étape consiste en l'intégration des vues définies ci-dessus dans la
perspective que l'on vient de créer. Afin de pouvoir définir les différentes
vues, nous créons l'extension \texttt{perspectiveExtension} et on la relie avec
la perspective en attribuant son id avec l'id de la perspective.\\

Voyons l'intégration de la vue de la palette en détail : 
\begin{itemize}
  \item on ajoute une vue dans l'élément \texttt{perspectiveExtension} ;
  \item on passe la configuration des paramètres de la vue :
  	\begin{itemize}
    	\item on définit l'\texttt{id} de vue avec la valeur \texttt{org.eclipse.gef.ui.palette\_view} que l'on trouve dans la liste \ref{palette} ;
    	\item on définit le \texttt{relationship} pour le positionnement de la vue dans la perspective ;
    	\item on définit les autres paramètres selon les besoins.\\
	\end{itemize}
\end{itemize}

Pour voir le résultat dans GAMA une fois le plugin \texttt{msi.gama.application} lancé, on change la perspective (\texttt{Window / Open Perspective / Other}) et on choisit la perspective \texttt{GraphicalModelingPerspective} (voir figure \ref{GraphicalModeling}).
 
Ensuite on crée un projet Papyrus en choissant le langage de diagramme UML. Dans la vue \texttt{Properties} on attribue le \texttt{profil} de modèle à notre modèle \texttt{GamaModeling} (voir figure \ref{profi}).

\begin{figure}
  \centering
  \includegraphics[scale=.5]{img/gamaModel.png}
  \caption{\label{profi}Profile GamaModeling}
\end{figure}
Enfin on va avoir notre palette personnalisée dans la vue palette. Maintenant nous pouvons commencer à modéliser\ref{res}.

\begin{figure}
  \centering
  \includegraphics[scale=.3]{img/integDansGama.png}
  \caption{\label{res}Voici le resultat}
\end{figure}  
  
 
\chapter*{Conclusion}
\label{conclusion}
\addcontentsline{toc}{chapter}{Conclusion}

Durant ce projet, nous avons mené à bien différentes tâches distinctes bien précises qui ont conduit à l'objectif final : ajouter au sein du logiciel GAMA la possibilité de créer graphiquement un modèle PAML, ce qui jusqu'ici nécessitait un outil externe. La solution obtenue à l'issue du développement propose dans GAMA une perspective dédiée offrant une zone où apparaît le modèle, une palette spécifique donnant accès aux objets du modèle ainsi que différentes vues permettant de l'enrichir ou de gérer sa construction. Puisque l'ensemble des opérations sont réalisées via l'interface de modélisation graphique, aucun travail textuel n'est plus nécessaire pour la définition du modèle. Nous avons donc bien répondu au besoin initial explicité dans le sujet du projet en rendant accessible ces outils à un utilisateur \og basique\fg, au sein même de GAMA.

Pour cela, il nous a fallu approfondir notre connaissance d'Eclipse. Tout d'abord les notions de perspectives, de vues et surtout les mécanismes permettant leur création et leur personnalisation. Ensuite apprendre à utiliser un \textbf{RCP}\footnote{Rich Client Platform} Eclipse, configurable via un plugin. Il nous a fallu également étudier et comparer différents outils de modélisation existants puis prendre en main l'outil Papyrus que nous avons choisi d'utiliser. Ces tâches distinctes ont finalement trouvé leur application dans la configuration du plugin définissant l'environnement de modélisation graphique personnalisé et son intégration dans GAMA.\\

En l'état actuel des choses, si la définition du modèle est désormais possible de façon graphique, il faut envisager comme suite à donner à ce projet le traitement du fichier XMI obtenu via la modélisation graphique. Il reste en effet à \textit{parser} ce fichier pour obtenir le formatage spécifique au modèle d'entrée pour GAMA. Cette partie technique sera facilité d'une part par le fait que le fichier XMI utilise un formatage \textbf{ecore} facile à exploiter, et d'autre part puisqu'il sera possible de s'appuyer sur un \textit{parser} déjà existant\footnote{celui qui jouait exactement le même rôle quand les modèles étaient produits graphiquement par BeoModeler.}.

D'autre part, une fois que l'outil que nous avons développé aura été testé en situation par les utilisateurs finaux, il pourra peut-être être envisagé -- si les développeurs de GAMA le souhaitent -- un intégration pérenne de cet outil au sein du projet.\\

Nous avions choisi ce projet dans le but d'approfondir notre connaissance du framework d'Eclipse et des possibilités offertes par sa structure modulaire : ajout de fonctionnalités par le biais de plugins, création de logiciel autonome basé sur Eclipse. Ces possibilités font la richesse, mais également la complexité d'Eclipse et des projets basés sur Eclipse. Cette expérience a été pour nous une bonne façon d'aborder ces structures que nous aurons peut-être à réutiliser un jour.

\begin{abstract}
  GAMA est une plate-forme de simulation utilisant un méta-modèle basé sur UML. Il permet de réaliser la modélisation d'un système géographique complexe à entités mobiles. La modélisation était jusqu'ici réalisée soit sous forme textuelle, soit graphiquement à l'aide d'un outil externe : BeoModeler.

  Ce projet a consisté à développer un plugin eclipse de modélisation graphique qui permette la création d'un modèle directement au sein de GAMA. Il a d'abord fallu pour cela faire un état des lieux des approches possibles, puis choisir et utiliser un outil de modélisation déjà existant. Ensuite il nous a fallu construire et configurer un plugin intégrant la fonctionnalité que nous devions implémenter, et pour finir intégrer notre plugin au sein de GAMA.

Chacune des étapes du travail a soulevé des difficultés techniques qu'il a fallu surmonter en utilisant différentes sources de documentation sur chacun des outils impliqués. En ce qui concerne GAMA, nous avons même pu parfois consulter Nicolas Marilleau, l'un de ses développeurs.
\end{abstract}

\end{document}
